perm filename STEVE.LE1[ESS,JMC] blob
sn#043804 filedate 1973-05-18 generic text, type C, neo UTF8
COMMENT ā VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002 FOONLY AS A NETWORK RESOURCE
C00018 ENDMK
Cā;
FOONLY AS A NETWORK RESOURCE
In accordance with our discussion on Monday and a discussion
with Larry on Thursday, I have prepared this memorandum on
converting Foonly into a network resource. Three variants of the
plan cost $340,000, $700,000, and $1,000,000 respectively.
1. Larry has told me some things about the results of
various improvements in NCP programs that give me a higher
subjective probability that operating displays over the network can
be done without serious degredation of performance. Therefore, I
propose the following experiment in connection with Foonly. A
PDP-11/45 be procured and attached to our IMP using commercially
available hardware. I don't yet know who makes it or what it costs,
but it is not excessive. The Datadisc display system and the
keyboard multiplexer will then be attached to the PDP-11. The
PDP-11 will be attachable either to the IMP or the PDP-10 IO-bus.
(An alternative is to make the display processor and the keyboard
multiplexor pluggable to either the PDP-11 or the PDP-10). In this
way, we can debug a system where the displays are connected to the
PDP-10 and later to Foonly through the net. When they are connected
to the net, other network computers are then directly accessible
from the display system. At some point, I would like to replace the
Datadisc by ic-memory so we can get the arbitrary character set and
other flexibility that I advocate for the standard display system.
If it all works the network will then become the standard way of
using our machine just as you propose. I have a good person in mind
to work on this, but it will be necessary to replace him on other
tasks.
2. We will put two people on getting TENEX ready to run on
Foonly. We anticipate having to improve TENEX in the following
respects: it must run efficiently with about 100 users (our present
system runs with 50), it must run efficiently with a large file
system (at present TENEX requires a disk audit after every system
crash which would be prohibitive), TENEX must support displays in a
way that is not just an imitation of a teletype (this is required
whether the displays run over the network or not), TENEX must
support our special hardware, and finally TENEX must support the
user microcode provided by Foonly. All these things can be done
within TENEX and we may be able to get BBN to do some of them. We
will take part in the TENEX user group activity.
It will also be necessary to do some software to take
advantage of the fact that Foonly allows 23 bit addresses in some
contexts. This was put in at the instigation of the PLANNER, etc.
people. One of the major attractions of Foonly as a network
resource will be this large addressing space.
3. In order to be a proper resource, Foonly needs more
memory. Because the 64K D.E.C. memory dating from 1966 is
unreliable and diffficult to interface, I propose including at least
128K of additional memory in the initial plan. However, if
substantial network use develops, I think that 512K to 1024K can be
added and will be cost-effective to ARPA, because Foonly's speed
will get more computation per memory dollar than would putting the
memory on a slower machine.
There are several schemes for adding memory to Foonly. One
is to buy it with interface from Ampex or Systems Concepts. The
Systems Concepts memory scheme is quite expensive, but, according to
Larry, has features that may recommend it in the Foonly case as well
as for Illiac. Another plan is to duplicate our present interface.
4. Our present swapper is the ancient Librascope. It has
only 5,000,000 of its original 12,000,000 words left and it may
break down irrevocably at some time. The way we use it now, it can
support about 56 users. To support 100 users many of whom will have
large programs will require a bigger faster swapper or the use of
secondary swapping to the 3330. We don't have a proposal for this
yet.
5. We also propose to get a manager for the project. It is
possible that Ralph Gorin may be suitable or we may have to hire
someone from the outside. When the system is serving network users,
we will need at least one person whose main job will be dealing with
outside users, and a manager who controls the facility well enough
to be sure that it serves the outside users well.
6. There are two plans for debugging Foonly. The old plan
calls for integrating Foonly into the present system with minimal
disturbance and minimal cost. It is described in the file
PLAN[F,DWP] in our system.
7. The second plan is cleaner, and is designed to produce a
Foonly system with all new hardware and involves no disturbance to
our present system. It is more expensive.
The plan starts by connecting the bare Foonly processor to
the PDP-10. In this connection Foonly is an I-O device to the
PDP-10 and the PDP-10 can control Foonly while continuing
time-sharing. To Foonly, the PDP-10 is the console computer and has
access to the internal registers and timing chains of Foonly. This
will permit Foonly to be debugged expeditiously. In my opinion, the
development of this method of debugging complicated digital hardware
is a sufficient scientific justification for completing the Foonly
project. It also works in the first plan.
When the processor is debugged, separate memory is attached
to Foonly using a new memory buss. It is believe that the buss can
be purchased with the memory, for example, from Systems Concepts.
Next a new swapping device, a new rented 3330, and the third
port on the IMP are attached and TENEX is debugged. At this point,
the network users can be allowed on.
Finally, the Stanford special I-O devices are attached, the
3330 on the PDP-10 goes off rental, and the 128K Ampex memory on the
PDP-10 is switched over to Foonly. The PDP-10 remains as the
console computer of Foonly and is usable for other purposes in a
limited way.
It is estimated that this scheme will take two more months
to complete than the first scheme, although the time may be saved.
BUDGET
The short time available for completing this memorandum did
not permit precise estimates of costs. I think the present
estimates err on the generous side but not by much.
1. The minimal plan described orally on Monday and in
written form as FOO73A[ESS,JMC] on our system costs $240,000 for
hardware and personnel assuming D.E.C. gives the $67,500 worth of
parts and services they have offered. As you recall, this offer has
some conditions attached to it that need to be negotiated.
2. I estimate the PDP-11/45 for networking the display
system at $26,000. Upgrading the display system to arbitrary
characters and flexible graphics would cost another $75,000 if this
were to be done at this time. Six man months of programming
associated with this task will cost another $10,000.
3. System Concepts quotes $128,000 as a maximum price for
supplying and additional 128K of core interfaced to Foonly
specifications. Full network service will require at least 512K of
core. It is hard to believe we would have to pay $1 per word for
this even fully interfaced. Let us guess $320,000 for this variant.
4. A new swapper might cost $200,000, but this is the
weakest estimate, because we don't know much about what is on the
market, and it is hard to estimate how much will be required since
it will depend on what size jobs the users choose to run.
5. We are presently paying IBM about $5000 per month in disk
rental, and we estimate that network use might cause this
requirement to double, but there will probably be something even
more cost-effective than the 3330 in a couple of years. If the
Datacomputer is reliable and if good transfer rates can be obtained,
we might be able to reduce our local storage requirements.
6. The plan for providing Foonly with all new hardware will
probably cost another $50,000 in parts for a new I-O buss and
another $10,000 in engineering time to implement.
7. We estimate another 3 man years for software development
costing $75,000 with overhead.
Thus we have the following costs:
1. Minimal plan - Foonly in present Stanford system with 128K new
core with copy of present interface $340,000 (ARPA's exposure would
be only $240,000 if the new core were purchased only after the
hardware worked).
2. Foonly in present system with displays on IMP and TENEX
implemented in parallel with hardware completion. 128K of memory
from Systems Concepts. $700,000
3. Foonly with all new hardware operating on 512K of new memory -
Displays upgraded to proposed network standard - $1,000,000. For
this we get the equivalent of 10 PDP-10s.
I have deliberately rounded the numbers in the last two
variants in order to emphasize the approximateness of the costs.
I note that I have not got the personnel costs at all right,
because of including overhead in some estimates and omitting it in
others. Les will have the honor of fixing it.
The system once running will require about three people
beyond our normal staff for making it fully useful as a network
resource.